@RyanGlScott Can you give this a review?

• The README changed the version of base-compat to 0.8.0. Should this also be changed in the .cabal file?
• Since Data.Traversable.Compat was removed, we don't need to check for it in run-check.sh, right?
• Since we no longer have GHC.Generics.Compat, I don't think we need ghc-prim as a dependency.
• You mentioned in the .cabal file that base-compat will not add any orphan instances. Does this mean we won't reexport base-orphans instances from .Compat modules? (e.g., reexport Foldable ((,) a) from Data.Foldable.Compat.

I pushed an other commit that addresses some of your comments. Can you take an other look.

I would update the version in the cabal file before pushing to Hackage (which is hopefully soon).

I would also keep base-compat and base-orphans separate for now. If a user want's to use both, he needs one additional import. That's not ideal, but I still think the right thing until we have sorted everything out. Let's first make sure that we consolidated all orphans in base-orphans and that we get community consensus. As things currently are it would e.g. not be possible to use lens and base-compat in the same project.

Alright, I can understand the need to be cautious about it. When I get some time (perhaps this weekend), I can do a more thorough job of going through the GHC release notes to find some more obscure orphan instances.

The rest of the pull request looks great to me.

By the way, doesn't your errorcall-eq-instance package currently reexport base-compat? It may be a good idea to redirect users to base-orphans instead from its Hacakge page. Up to you.

@RyanGlScott yes, we need to release base-orphans first and make errorcall-eq-instance depend on it + change the deprecation message, before we release base-compat-0.8.0.

I released base-orpahans and updated errorcall-eq-instance.